Software development control panels : concepts, a toolset and experiences

This thesis discusses a concepts, guidelines, a toolset and experiences with defining and implementing on-line visual displays of software development progress, control panels. Control panels group sets of measurement visualizations providing a multi-dimensional, integrated view of development status. Control panels are developed at various organizational levels, serving the information needs of different stakeholders. Navigation between different control panels enables users to drill down to view more detailed information on, e.g., a particular project or on the progress of a particular development activity. In the constructive part of the work, I describe concepts, and a toolset that can be used for defining and implementing control panels. In addition, I provide guidelines for grouping measures into control panels, and discuss how measurement programs can be partitioned into control panels. The toolset, built as a "proof-of-concept" consists of a central measurement database, a visualization client, and a set of data importers that transfer data from external corporate repositories into the measurement database. The empirical part discusses our efforts to define and implement control panels in four high-technology companies in Finland. Framed in the context of "constructive action research", the cases are first described individually, according to the main steps of the action research cycle, then compared in a cross-case analysis. Our results—we succeeded in implementing control panels in only one of four organizations—indicate that the development of control panels requires a substantial investment and commitment by the organization, but that it can be feasible even in small organizations. The main obstacles hindering the implementation were organizational and human in nature, and more related to measurement program implementation in general than to tool support per se. Interestingly, the organizations did not consider measurement definition, i.e., the selection of "metrics" to be problematic. Success factors identified included management commitment, dedicated measurement personnel, and organizational change management. While limited, our experiences with the use of control panels show that they were felt to be more valuable by management than by the collocated project personnel. We thus hypothesise that the usefulness of control panels increases with project size and geographical distance. In the future it would be interesting to develop control panels for distributed software development projects, in which informal status communication is more difficult.reviewe

Continuous and collaborative technology transfer : Software engineering research with real-time industry impact

Context: Traditional technology transfer models rely on the assumption that innovations are created in academia, after which they are transferred to industry using a sequential flow of activities. This model is outdated in contemporary software engineering research that is done in close collaboration between academia and industry and in large consortia rather than on a one-on-one basis. In the new setup, research can be viewed as continuous co-experimentation, where industry and academia closely collaborate and iteratively and jointly discover problems and develop, test, and improve solutions. Objective: The objective of the paper is to answer the following research questions: How can high-quality, ambitious software engineering research in a collaborative setup be conducted quickly and on a large scale? How can real-time business feedback to continuously improve candidate solutions be gained? Method: The proposed model has been created, refined, and evaluated in two large, national Finnish software research programs. For this paper, we conducted thematic interviews with representatives of four companies who participated in these programs. Results: The fundamental change is in the mindset of the participants from technology push by academia to technology pull by companies, resulting in co-creation. Furthermore, continuous cooperation between participants enables solutions to evolve in rapid cycles and forms a scalable model of interaction between research institutes and companies. Conclusions: The multifaceted nature of software engineering research calls for numerous approaches. In particular, when working with human-related topics such as company culture and development methods, many discoveries result from seamless collaboration between companies and research institutes.Peer reviewe

DevOps in practice : A multiple case study of five companies

Context: DevOps is considered important in the ability to frequently and reliably update a system in operational state. DevOps presumes cross-functional collaboration and automation between software development and operations. DevOps adoption and implementation in companies is non-trivial due to required changes in technical, organisational and cultural aspects. Objectives: This exploratory study presents detailed descriptions of how DevOps is implemented in practice. The context of our empirical investigation is web application and service development in small and medium sized companies. Method: A multiple-case study was conducted in five different development contexts with successful DevOps implementations since its benefits, such as quick releases and minimum deployment errors, were achieved. Data was mainly collected through interviews with 26 practitioners and observations made at the companies. Data was analysed by first coding each case individually using a set of predefined themes and thereafter perform a cross-case synthesis. Results: Our analysis yielded some of the following results: (I) software development team attaining ownership and responsibility to deploy software changes in production is crucial in DevOps. (ii) toolchain usage and support in deployment pipeline activities accelerates the delivery of software changes, bug fixes and handling of production incidents. (ii) the delivery speed to production is affected by context factors, such as manual approvals by the product owner (iii) steep learning curve for new skills is experienced by both software developers and operations staff, who also have to cope with working under pressure. Conclusion: Our findings contributes to the overall understanding of DevOps concept, practices and its perceived impacts, particularly in small and medium sized companies. We discuss two practical implications of the results.Peer reviewe

Towards “Honest Signals” of Creativity – Identifying Personality Characteristics Through Microscopic Social Network Analysis

AbstractThis paper presents preliminary results on predicting individual creativity based on interpersonal interaction patterns. We combine insights from analyzing communication in an E-mail student network of a distributed course with measurements of interaction by sociometric badges for 23 programmers in Northern Europe. In the first case study we measure communication patterns of 23 software developers in a Nordic country through sociometric badges over a period of 4 weeks, associating it with creativity and productivity collected by a daily questionnaire. At the same time we collected individual trust through another questionnaire. We found that the more central people are in the network, the more trusting they are, and the less they oscillate between low and high states of energy, the more trusting they are. The second case study is based on a sample of 17 students from a German university participating in a multinational course. We show that e-mail behavior is associated with personality type as measured by the FFI personality test. We found that the larger degree and betweenness centrality of students in the e-mail course network is, the more agreeable and less neurotic they are. The faster students respond to e-mail, the more open and agreeable they are. The smaller the contribution index of students is, i.e. the less e-mails they send relative to other team members, the more neurotic they are.We speculate that there might be two different types of creativity, “lonely genius” - feeling most creative when on his/her own with lower trust in others, and “swarm creative” - most creative when in the midst of other people, and with higher trust

Status Quo in Requirements Engineering : A Theory and a Global Family of Surveys

Requirements Engineering (RE) has established itself as a software engineering discipline over the past decades. While researchers have been investigating the RE discipline with a plethora of empirical studies, attempts to systematically derive an empirical theory in context of the RE discipline have just recently been started. However, such a theory is needed if we are to define and motivate guidance in performing high quality RE research and practice. We aim at providing an empirical and externally valid foundation for a theory of RE practice, which helps software engineers establish effective and efficient RE processes in a problem-driven manner. We designed a survey instrument and an engineer-focused theory that was first piloted in Germany and, after making substantial modifications, has now been replicated in 10 countries worldwide. We have a theory in the form of a set of propositions inferred from our experiences and available studies, as well as the results from our pilot study in Germany. We evaluate the propositions with bootstrapped confidence intervals and derive potential explanations for the propositions. In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from the replication studies conducted in 10 countries with participants from 228 organisations. Our results represent a substantial step forward towards developing an empirical theory of RE practice. The results reveal, for example, that there are no strong differences between organisations in different countries and regions, that interviews, facilitated meetings and prototyping are the most used elicitation techniques, that requirements are often documented textually, that traces between requirements and code or design documents are common, that requirements specifications themselves are rarely changed and that requirements engineering (process) improvement endeavours are mostly internally driven. Our study establishes a theory that can be used as starting point for many further studies for more detailed investigations. Practitioners can use the results as theory-supported guidance on selecting suitable RE methods and techniques.Peer reviewe

The Design of the Software Workmate Process-Centered Software Engineering Environment

OF THE TECHNOLOGY MASTER'S THESIS iii Author and name of the thesis: Casper Lassenius: The Design of the Software Workmate Process-Centered Software Engineering Environment Date: 23.09.1996 Number of pages: 86 Department: Faculty of Mechanical Engineering, Department of Industrial Management Professorship: Tik-76 Supervisor: Professor Reijo Sulonen Instructor: M.Sc. Kari Alho, Helsinki University of Technology The goal of the thesis is to present the Software Workmate process-centered software engineering environment. The focus is on the concepts and the general design, but the implementation of the process engine component is also described. The thesis begins with a presentation of the motivations for the work, followed by an overview of the research into the software process: concepts, life-cycle models and modeling formalisms. The discussion on software engineering environments contains requirements, architectures, existing process-centered environments; and issues related..

TKK-DISS-2135

Ohjelmistoliiketoiminnan ja-tuotannon laboratori